Some file systems use a data journal to preserve consistency of data. When data is to be written to a file, it is first saved in a high speed persistent storage medium (e.g., a hard disk) for the data journal along with the position and size in the original file where the data will be saved. The journal entry is then saved to persistent storage (e.g., a hard disk drive). At this point, the file write can be recovered from the journal entry on the persistent storage in the event of an interruption such as a power failure. Accordingly, applications relying on the data having been written can proceed once the journal entry is added to the persistent storage. The actual copying of the data to the file may proceed under the control of the persistent storage. For example, writes may be reordered based on a cylinder seek position or a location of a rotational disk head. Similarly, processes for copying the data from the data journal to the file may operate asynchronously and in parallel. In this context, maintaining data consistency refers to ensuring that after a system crash or power failure, attributes and data of a file are either the values they had prior to the write or the values after a successful write. Inconsistent data would have a mix of the two, or even be corrupted with other values.
For writes of sufficiently small amounts of data, the operation may automatically be atomic (i.e., indivisible). An example of this is when the data size is equal to the size of a central processing unit (CPU) cache line (e.g., 64 bytes for an Intel© x86 processor with support for transactional state extensions (TSX)). Thus, when an instruction to write 64 bytes to a file are executed, the write will either be successful and the file will be updated or, in the event of power failure, the write will fail and the file will remain unchanged.
In a Zettabyte File System (ZFS), blocks are written atomically by writing a replacement page to persistent storage and then updating a pointer in the file system from the original page to the replacement page. Since the pointer (e.g., a 64-bit pointer) is written in a single operation, in the event of an interruption, the file either contains the original page or the replacement page, but never contains a corrupted, mixed page.